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Foreword 

This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 

The present document is part 3 of a multi-part deliverable covering end-to-end Quality of Service in TIPHON systems, 
as identified: 

Part 1: "General aspects of Quality of Service (QoS)"; 

Part 2: "Definition of Quality of Service (QoS) Classes"; 

Part 3: "Signalling and Control of end-to-end Quality of Service"; 

Part 4: "Quality of Service Management"; 

Part 5: "Quality of Service (QoS) measurement methodologies"; 

Part 6: "Actual measurements of network and terminal characteristics and performance parameters in TIPHON 
networks and their influence on voice quality"; 

Part 7: "Design Guide for elements of a TIPHON connection from an end-to-end speech transmission 
performance point of view". 
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Introduction 



The present document forms one of a series of technical reports and technical specifications by TIPHON Working 
Group 5 addressing aspects of Quality of Service (QoS) in TIPHON systems. These documents are all part of a single 
document TS 101 329, the structure of which is illustrated in figure 1. 
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Figure 1 : TIPHON WG5 QoS documentation structure 



The present document describes a framework for the signalling and control of end-to-end Quality of Service in 
TIPHON Systems 
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1 Scope 



The present document describes a framework for enabling the end-to-end QoS levels defined in TS 101 329-2 [2] to be 
signalled and controlled in TIPHON systems. The mechanisms involved operate between TIPHON terminals, IP 
telephony Service Providers (IPTSPs), and network transport systems, and provide a flexible means for the dynamic 
allocation of QoS parameters across these entities in order to meet the QoS Service Classes defined in TS 101 329-2 [2]. 
The functional entities involved in the QoS signalling and control are defined, as are the requirements of the reference 
points between these functional entities. The QoS parameters and information flows used to establish the required user 
QoS levels are also specified. 

The Application Plane mechanisms described in the present document are intended to be independent of the transport 
QoS mechanisms used within the underlying IP networks. 

The emphasis of the present document is on media QoS (primarily voice, but the mechanisms are also applicable to 
other media types). Issues related to performance of the signalling channels are outside the scope of the present 
document. 

The present document describes how this QoS framework fits into the overall TIPHON architecture and details of the 
signalling involved are described in TS 101 471 [4]. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

IP Telephony Service Provider (IPTSP): business entity providing IP Telephony Services 

Interconnect Function (ICF): functional Entity that interconnects transport domains with entities outside of the 
transport domain. It polices authorized media flows between two transport domains to ensure they are consistent with 
the QoS policy specified by the relevant manager 

Quality of Service Manager (QoSM): functional entity that mediates requests for end-to-end QoS in accordance with 
policy determined by the QoSPE. It communicates with, other QoSMs and with TRMs to determine, establish and 
control the offered QoS 

Quality of Service Policy Element (QoSPE): functional entity that manages IP Telephony QoS policies and provides 
authorization of permitted and default QoS levels. It receives requests from and issues responses to QoSMs to establish 
the authorized end-to-end QoS levels 

service domain: functional entity representing the domain of control of an IPTelephony Service Provider 

Transport Domain (TD): functional entity representing a collection of transport resources sharing a common set of 
policies and QoS mechanisms and under common administrative control 

transport network: collection of transport resources which provide transport functionality 

transport network operator: business entity operating a Transport Network 

Transport Policy Entity (TPE): functional entity that maintains the policies of a Transport Domain 

Transport Resource Manager (TRM): functional entity that applies a set of policies and mechanisms to a set of 
transport resources to ensure that those resources are allocated such that they are sufficient to enable QoS guarantees 
across the domain of control of the TRM 

Transport Functionality (TF): functional entity representing the collection of transport resources within a Transport 
Domain which are capable of QoS control 

User Equipment (UE): functional entity representing the domain of control of an IP Telephony End User 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ATM Asynchronous Transfer Mode 

DiffServ Differentiated Services 

GSM Global System for Mobile communications 

ICF InterConect Function 

ISDN Integrated Services Digital Network 

IP Internet Protocol 

IPTSP IP Telephony Service Provider 

IntServ Integrated Services 

MPLS Multi Protocol Label Switching 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

QoSM Quality of Service Manager 

QoSPE Quality of Service Policy Element 

RSVP Resource Reservation Set-Up Protocol 

RTP Real-Time Transport Protocol 

SCN Switched Communications Network 

SLA Service Level Agreement 
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TCP 

TD 

TF 

TPE 

TRM 

UDP 

UE 

VoIP 



Transmission Control Protocol 
Transport Domain 
Transport Functionality 
Transport Policy Element 
Transport Resource Manager 
User Datagram Protocol 
User Equipment 
Voice over IP 



QoS Architecture 



4.1 



TIPHON Architectural Planes 



The Generalized TIPHON Architecture is shown in figure 2 (see TS 101 314 3]). 




Figure 2: Generalized TIPHON Architecture 

End-to-end QoS signalling and control will in general involve QoS information flows in each of the architectural 
planes. 

The Required end-to-end QoS levels are established within the IP Telephony Application Plane between End Users and 
Service Provider(s) and decisions determining QoS, specific to the application, will take place in the IP Telephony 
Application Plane (e.g. codec type, packetization etc). 

The IP Transport Plane (IP Network Operators) provides a QoS service to the Application Plane (Service Providers). 
QoS control within the IP Transport Plane is the responsibility of the IP Network Operators. 

4.1 .1 IP Telephony Application Plane 

Within this plane, QoS parameters specific to the application are requested, authorized, signalled, controlled and 
accounted. 
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4.1.2 IP Transport Plane 



Within this plane, general non-application specific parameters effecting QoS must be controlled and accounted to 
achieve the QoS requirements requested by the application. 

4.1.3 Management Plane 

Within this plane QoS management entities applicable to both application and transport planes will reside and 
information flows applicable to QoS management will terminate. 

4.2 Service and Transport Domains 

A TIPHON-compliant deployment will in the general case be made up of a number of separate Service Domains, each 
representing the domain of control of an End-User or IPTSP. These domains will generally be restricted to IP 
Telephony Application plane functionality, e.g., gatekeepers, softswitches, call agents, etc. 

Similarly, a TIPHON-compliant system will, in general, also be made up of a number of separate Transport Domains. 
Transport Domains consist solely of transport related functionality; this includes IP routers and switches, firewalls etc. 
Each Transport Domain may have its own QoS policies and/or differ from other domains in terms of administrative 
control (e.g. Network Operator), QoS mechanisms (RSVP/IntServ, DiffServ, MPLS), access, metering, addressing 
schemes (global, local) and transport protocol (IPv4, IPv6), etc. 

Since these policies are local, functional entities are needed to interface to other domains. These entities are called 
Interconnect Functions. 

The general TIPHON deployment is illustrated in figure 3. 

4.2.1 End-to-End QoS Control 

End-to-end QoS control across multiple domains may be achieved in one of two ways: 

a) By having an IP Telephony Application Service Domain control each Transport Domain. The Service Domain 
would request the transport resources with QoS from each of the Transport Domains and establish the 
interconnect in a controlled fashion. 

b) By means of end-to-end signalling within and between Transport Domains which share common policies. 
These two mechanisms are explained below. 
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4.2.1.1 



IP Application Plane control 



In this first case, the routing of the call between Transport Domains is under the control of the IPTSPs. In this general 
case, where the Transport Plane is made up of a number of heterogeneous Transport Domains, each domain may have 
its own QoS mechanisms and policies. 

Figure 3 illustrates the general case where a number of separate IPTSPs and Transport Domains are involved in a call. 
Call-Control signalling takes place in the IP Telephony Application Plane between IPTSPs and between end users and 
IPTSPs. Media flows are between End Users and Transport Domain and between Transport Domains. QoS signalling 
and SLAs are between End Users and IPTSPs and between IPTSPs and follow Call Routing. Between each IPTSP 
involved in the call and its associated Transport Domain(s) QoS SLAs then ensure that the required QoS parameters are 
met by each Transport Domain involved in the call. 




< ► Media Path 

< ► QoS Signalling 

< ► Call Signalling 



Figure 3: Generalized TIPHON Architecture with Service Domain end-to-end QoS Control 
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4.2.1.2 



Transport Plane control 



In this case, the QoS control of the call between Transport Domains is performed by the local Transport Domain and by 
agreement between Transport Network Operators. QoS SLAs are required between End-Users and IPTSPs and between 
Transport Network Operators. The End-Users may first register with their IPTSP and receive authorization to make a 
call before establishing a media connection with the local Transport Network Operator. 

This approach is a viable option where the Transport Plane comprises a single homogeneous policy space. Addressing, 
Access and QoS mechanisms and policies all have to be uniform for this case to work. 

Figure 4 illustrates the case where end-to-end control of QoS is performed by signalling in the Transport Plane with 
QoS authorization by the access Service Provider. 




•^ ► Media Path 

•^ ► QoS Signalling 

■4 ► Call Signalling 



Figure 4: Generalized TIPHON Architecture with Transport Plane end-to-end QoS Control 

Hybrid situations are possible where a Service Domain may control several Transport Domains or one Transport 
Domain may control others. Some of these configurations are shown in annex A. 

4.3 QoS Functional Elements 

The TIPHON QoS mechanisms have elements in both the Transport and in the IP Telephony Application plane. They 
are described in this clause. 

The following Functional Elements are involved in the QoS Control Framework. 

4.3.1 QoS Service Manager (QoSM) 

A functional entity that mediates requests for end-to-end QoS in accordance with policy determined by the QoSPE. It 
communicates with, other QoSMs and with TRMs to determine, establish and control the offered QoS. 

4.3.2 QoS Policy Entity (QoSPE) 

A functional entity that manages IP Telephony QoS policies and provides authorization of permitted and default QoS 
levels. It receives requests from and issues responses to QoSMs to establish the authorized end-to-end QoS levels. 
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4.3.3 Transport Resource Manager (TRM) 

A functional entity that applies a set of policies and mechanisms to a set of transport resources to ensure that those 
resources are allocated such that they are sufficient to enable QoS guarantees across the domain of control of the TRM. 

4.3.4 Transport Policy Entity (TPE) 

A functional entity that maintains the policies of a Transport Domain. 

4.3.5 Interconnect Function (ICF) 

A functional entity that interconnects Transport Domains with entities outside of the Transport Domain. It polices 
authorized media flows between two Transport Domains to ensure they are consistent with the QoS policy specified by 
the relevant manager. 

4.3.6 Transport Functionality (TF) 

A functional entity representing the collection of transport resources within a Transport Domain which are capable of 
QoS control. 

4.3.7 Relationship between Functional Entities 

The relationship between these QoS Functional Entities is shown in figure 5. 



Other 
Service Domains 




QoS Signalling 



Figure 5: TIPHON QoS Functional Entities 
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4.4 QoS Reference Points 



The QoS reference points indicated in figure 5 are derived from the general reference points defined in TS 101 314 [3], 
They are used for QoS only and are distinguished from their equivalent general reference points by the addition of the 
letter Q. They are extensively explained in clause 8. Here a short description of each is given. 

4.4.1 Reference point QC1 

The QoS information flow between a QoSM and a User Equipment QoSM is captured in the QC1 reference point. The 
information flow across this reference point communicates QoS related bearer information between an End User and 
the End User's ITSP in the IP Telephony Application Plane. 

4.4.2 Reference point QC2 

Information flowing between two QoSMs in different service domains is captured in QC2. The information flow across 
this reference point communicates QoS related bearer information between domains (ITSPs) in the IP Telephony 
Application Plane. 

4.4.3 Reference point QS4 

Between a QoSM and a QoSPE. The information flow across this reference point communicates QoS policy 
information relating to the establishment of a bearer with specified QoS levels. 

4.4.4 Reference point QT2 

Between a QoSM and its associated TRM(s). The information flow across this reference point communicates QoS 
related transport flow information between a Service Domain and an associated Transport Domain. The information on 
QT2 communicates the QoS related characteristics required of the transport flows that will carry the media flow, the 
properties of the media flow, and addressing information related to the transport flows. 

4.4.5 Reference point QT1 

Between a User Equipment QoSM and an associated Transport Domain. The QoS information flow across this 
reference point communicates the QoS related characteristics required of the local loop transport flows that will carry 
the media flow, the properties of the media flow, and possibly addressing information related to the transport flows. 

4.4.6 Reference point QI1 

Between a TRM and a TRM in another Transport Domain. The QoS information flow across this reference point 
communicates the QoS related characteristics required of the local loop transport flows that will carry the media flow, 
the properties of the media flow, and possibly addressing information related to the transport flows. 

4.4.7 Reference point QI2 

Between two TRMs in different Transport Domains. The information flow across this reference point communicates the 
QoS related characteristics required of the interconnect transport flows that will carry the media flow, the properties of 
the media flow, and possibly addressing information related to the transport flows. 

4.4.8 Reference point QI3 

Between a TRM and an ICF. The information flow across this reference point controls the Interconnect Function and 
enables it to perform its interworking and policing functions. 

4.4.9 Reference point QI4 

Between a TRM and its associated TPE. The information flow across this reference point is for further study. 
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4.4.10 Reference point QI5 

Between a TRM and its associated TF. The information flow across this reference point is for further study. 



5 Characterizing QoS 

5.1 User, Application and Transport Level QoS Parameters 

Four end-to-end QOS Classes applicable to TIPHON systems are defined in TS 101 329-2 [2]. These TIPHON QoS 
classes are expressed in terms of the users perception of QoS and they form a suitable basis for QoS agreements 
between the IPTSPs and End Users. 

Within the IP Telephony application the subjective user level QoS Class is determined by a number of engineering 
parameters which form part of the User Equipment, the network based equipment and the performance of the network 
itself. Examples are the choice of codec, any forward error correction deployed, the packetization algorithm used, the 
codec frame size, the algorithms used for handling packet delay variation at the receiver, the size of jitter buffers 
deployed, error concealment techniques within the decoder, and equipment processing delays. At the application level, 
QoS agreements relating to the registration of User Equipment with IPTSPs, must be specified in terms of these 
application based parameters. 

In practice most of these parameters will be determined by the User Equipment design, and control of end-to-end QoS 
within the application will be reduced to the control of a number of basic network and equipment related parameters. 
Specifically: 

• Maximum end-to-end delay; 

• Maximum end-to-end delay variation; 

• Maximum Packet loss. 

End-to-end control of these parameters is necessary and sufficient to ensure guaranteed speech quality across a 
particular speech path. Where multiple Transport Domains are involved in a call, the set of parameters must be 
specified and controlled in each domain if quality is to be specified and controlled. 

The QoS achievable at the application and user levels will depend ultimately on the performance of the underlying 
transport networks supporting the IP telephony service. In the Transport Plane therefore the mean end-to-end delay, 
delay variation and packet loss must be controlled. 

Figure 6 describes the parameters that are relevant for each level. 
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TIPHON Voice QoS Class 



I 



USER 



Codec, Frames per Packet, Frame Size, Jitter Buffer Delay, 

FEC (Redundancy), Overall One-Way Delay, 

Packet Loss 



I 



APPLICATION 



Packet Loss, Mean Delay, Delay Variation 




Figure 6: User, Application and Transport QoS Parameters 



5.2 Interfacing to the Transport Plane 

Although the QoS requirements arise from the IP Telephony application, the parameters must be controlled in the 
Transport Plane. The QoS requirements are speech quality related and are therefore independent of the mechanisms 
used to control Quality in the transport plane. Thus ATM, RSVP, DiffServ or MPLS or static network engineering 
could all be used to control the required QoS parameters, or even a mixture of these mechanisms where multiple 
Transport Domains are involved. The QoS requirements for a particular media flow must, however, be know to the 
Transport Plane in order that the parameters can be controlled to the required levels. 

For the purposes of interfacing to the transport plane a distinction is made between Transport QoS Parameters, which 
specify the QoS levels to be delivered, and a Traffic Descriptor, which enables the transport network to optimally 
manage the resources required. 

5.2.1 Transport QoS Parameters 

The Transport QoS Parameters (Maximum end-to-end delay, Maximum end-to-end delay variation, Maximum Packet 
loss) completely specify the QoS requirements of the transport flow carrying the bearer. 

The format in which these parameters are specified may vary depending on individual circumstances. Different levels of 
instantaneous control are possible and the way in which the parameters are specified will determine this. In general, 
there are three possibilities: 

1 . specification of whether QoS is to be controlled on the bearer. Best Effort speech communication implies that 
QoS levels are not specified; 

2. specification that any or all of the three parameters are to be controlled but that the values for the parameters are 
specified elsewhere, e.g. by service level agreements; 

3. specification of the absolute values for the three parameters. 
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These three possibilities are provided by the general format of the Transport QoS Parameter Group (see clause 9.2) 
which shall be as follows: 

Sub-Field 1: Control QoS 

ControlQoS (boolean) 

Sub-Field 4: Maximum end-to-end delay 

FixedDelay (boolean) 

MaxDelay (numeric) 

Sub-Field 5: Maximum end-to-end delay variation 

Fixed MaxDelay Variation (boolean) 

MaxDelayVariation (numeric) 

Sub-Field 6: Maximum Packet Loss 

FixedPacketLoss (boolean) 

MaxPacketLoss (numeric) 

The above parameters being defined as follows: 

ControlQoS: 

This parameter specifies whether QoS is to be specified or controlled over the bearer. If this parameter is not set then 
the rest of the fields in the Parameter Group shall be null fields. TIPHON Class 4 shall require this parameter being set 
to a null. 

FixedDelay: 

This parameter may be set for interactive voice communications. There is at present little difference between the 
maximum permitted end-to-end delay parameters for the three guaranteed TIPHON classes. When this parameter is set, 
unless specified otherwise in a service level agreement, the default value of 100 ms shall apply in all cases. When this 
parameter is set the MaxDelay parameter shall be null. For streaming applications (which are presently outside the 
scope of TIPHON) this parameter would be set to a null, as would the Max Delay parameter. 

5.2.2 Traffic Descriptor 

The Traffic Descriptor characterizes the resource requirements of a media flow. The QoS levels for a media flow shall 
be guaranteed only in the case that the flow remains conformant to its Traffic descriptor. The Traffic descriptor shall 
include the following parameters: 

• Peak Bit rate 

This is defined as the maximum rate of the media flow at which the transport domain is required to sustain QoS 
guarantees. (The overhead from RTP or equivalent framing shall be included in this figure). 

For constant bit rate (CBR) media flows, the Peak Bit Rate is sufficient to enable optimum resource utilization in the 
transport plane. 

• Maximum Packet Size 

This is defined as the maximum size of the media packets including the RTP overhead. 

The characterization of variable bit rate (VBR) media flows may require further parameters such as the average bit rate 
of the flow, or a parameter indicating the burstiness of the media flow. For transport resource optimization this 
information is likely to be derived from measurement within the Transport Plane rather than from the End-User or the 
IP Telephony Application Plane. The extension of the Traffic Descriptor to characterize VBR media flows is for further 
study. 
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6 Allocating the QoS Budget across Service and 

Transport Domains 

In the generalized model shown in figure 3 it is assumed that the TIPHON system is divided into a number of separate 
Transport Domains and Service Domains and that a call through the TIPHON system will in general pass through a 
number of such domains. 

End-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the 
required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment, as 
illustrated in figure 7. The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed 
that the performance of each domain is statistically independent from any other, in which case the overall accumulation 
of QoS parameter values may be calculated as follows: 

• delay is additive, i.e. D tot = Dj + D 2 + D n ; 

• packet loss accumulates on a probabilistic basis, i.e. P tot = 1-[(1-Pi)*(l-Pa)* (1-P„)]; 

• delay variation accumulates on an RMS basis, i.e. DV tot = sqrt[DVi 2 + DV 2 2 + DV n 2 ]; 

where D n is the mean one-way delay of Domain n; 

P n is the packet loss probability of Domain n; and 

DV n is the standard deviation of the delay variation of Domain n. 



User Equipment Budget 
M ► 



User 
Equipment 1 



End-to-End Budgets 



Transport Domain Budgets 



User Equipment Budget 

A ► 

► 




Figure 7: Allocation of TIPHON QoS Budgets 

The present document describes three ways in which to apportion the QoS budget between domains: 

• dynamic signalling of Transport QoS Parameters end-to-end between IPTSPs on a per call [or event] basis. 

• static Service Level Agreements (SLAs) between IPTSPs which define the Transport QoS parameters for calls 
passing through their domain of control. This approach will also require policies in the SLAs specifying the 
maximum number of domains end-to-end that will be involved in a call. 

• aggregation of Transport Domain resource and caching of information on its availability in which dynamic but 
infrequent signalling of Transport QoS parameters enables a knowledge of the Transport QoS Parameters that 
may be supported at any point of time to be ascertained. 

NOTE: The allocation of budgets between User Equipment and Network must be established before the call 

either by SLA at time of registration, or by dynamic signalling at call set-up, or by a combination of both. 
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6.1 Dynamic signalling of Transport QoS Parameters 

Dynamic signalling of Transport QoS Parameters allows an IPTSP to signal the QoS requirements on a per call basis. 

Call-Control signalling takes place in the Application Plane between IPTSPs, and between End-Users and IPTSPs. 
Similarly, QoS signalling takes place on the basis of SLAs between End Users and IPTSPs and between IPTSPs, and 
follows Call Routing. Between each IPTSP involved in the call, and its associated Transport Domain(s), Transport QoS 
Parameter signalling takes place, again on the basis of SLAs to ensure that the required Transport QoS Parameters are 
met by each Transport Domain involved in the call. Some of these parameters may be in the SLA and some signalled 
dynamically. Clause 9 describes the procedures used for dynamic QoS controlled call establishment. 

6.2 Specification of Transport QoS Parameters in Service Level 
Agreements 

SLAs are part of the peering agreement between IPTSPs. These may specify the Transport QoS Parameters for calls 
passing through their Transport Domain(s) of control, thereby obviating the need to signal these parameters on a per call 
basis. Where Transport QoS Parameters are specified in this way, end-to-end signalling may be restricted to resource 
availability to support Service Class (TIPHON QoS Class or possibly a Transport QoS Parametric class). 

6.3 Aggregation 

With aggregated transport resource reservation or bulk reservation the IP Telephony Application Plane reserves an 
amount of resources for media transport that is sufficient to support a number of media flows. This allows the 
application plane to more efficiently use allocated resources by using statistical multiplexing of variable bit-rate media 
streams. Using aggregated transport reservation also saves on signalling, as the Transport Plane may not need to be 
contacted for each call. 

Resource aggregation may be performed in the Transport Plane under the control of either Transport Network Operators 
or IPTSPs. Aggregation involves a quantity of transport resource with guaranteed QoS characteristics being allocated 
prior to the set up of an individual media flow. Individual media flows will then consume a portion of this. In both cases 
requests to set up a QoS controlled connection may therefore be made without exchanging QoS parameters on a 
per-flow basis. 

6.3.1 Aggregation under control of the TRM 

In the case where aggregation is controlled by the Transport Network Operators the role of the TRM will then be to 
monitor the allocation of this resource Mechanisms such as MPLS and IntServ may be used for this purpose. The IP 
telephony application is unaware of the aggregation taking place in the transport plane, therefore this case is outside the 
scope of the present document. 

6.3.2 Aggregation under control of the QoSM 

When control of the aggregated resource is by a Service Provider a QoSM may reserve a quantity of transport resource 
with quaranteed QoS characteristics prior to the set up of an individual media flow. This would be by agreement with 
the Transport Network Operator. The QoSM then maintains the availability of QoS reserved resource calculating the 
actual utilization of the aggregate resource. 

Resource aggregation requires aggregate bearer bandwidth management and connection admission control 
functionality. 

An aggregate resource has one source and one destination IP address in each Transport Domain. Multiple bearers are 
multiplexed, for example, by means of their port number using the same IP header belonging to an aggregate. When 
reserving aggregate resource the IP Telephony Application Plane shall send to the Transport Plane the aggregate IP 
address with for example, a range of port numbers, (to be multiplexed over the aggregate resource). It is desirable that 
all these ports shall be opened by the ICF, thus avoiding per -bearer communication between the IP Telephony 
Application and Transport Planes. 
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The following methods are identified for aggregate resource creation: 

a) provisioning on a semi-permanent basis (pre-assigned); 

b) dynamic aggregate resource establishment/clear down. A dynamic aggregate may also be implemented with 
optional bandwidth negotiation. 

Connection admission control to the aggregate resource shall be performed on a per bearer basis. The resource usage 
information may be used for connection admission control. 

Aggregate resource usage can be calculated by different methods, e.g.: 

a) traffic engineering methods taking into account Traffic Descriptors; 

b) resource usage measurements. 

Resource reservation renegotiation may take place at any time. For example when the resource usage of the aggregate 
flow exceeds a predetermined percentage of the reserved resource the allocation may be renegotiated or a new 
aggregate flow created. Similarly in low traffic conditions it may be desirable to renegotiate a lower aggregate 
reservation. 
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7 



QoS Primitives 



Figure 8 shows the general model for the QoS information flows introduced in clause 5. These include QoS information 
flows between IP Telephony Application Plane domains, between Transport Plane domains and information flows 
between an IP Telephony Application Plane domain and a corresponding Transport Plane domain. 

For end-to-end QoS control the information flows shall be exchanged between previous and subsequent IP Telephony 
Application Plane domains and/or Transport Domains. At each reference point information shall be exchanged via QoS 
Primitives. The figure shows the QoS Primitives defined at each of the reference points. 




Figure 8: Model of QoS information flows. 

NOTE: The model shows uni-directional end-to-end QoS establishment. The same model shall also apply in the 
bi-directional end-to-end QoS establishment case. 

7.1 QoS Primitives 

NOTE: Primitives required for renegotiation of properties are for further study. 

7.1.1 QC1&2 

The information flow across this reference point shall communicate QoS related bearer information between domains 
(ITSPs) in the IP Telephony Application Plane (QC2) or between User Equipment and a Service Domain (QC1). 

The following primitives are defined: 

QoSM request (QCl/2.QoSMreq) requests the establishment of a bearer conforming to a particular TIPHON Class of 
Service or with defined QoS characteristics. 
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QoSM confirm (QCl/2.QoSMconf) acknowledges the creation of a bearer conforming to a requested TIPHON QoS 
Class or with specified QoS characteristics. 

QoSM reject (QCl/2.QoSMrej) rejects the creation of a bearer conforming to a requested TIPHON QoS Class or with 
specified QoS characteristics. 

QoSM release request (QCl/2.QoSMrelreq) requests the release of a bearer. 

QoSM release confirm (QCl/2.QoSMrelconf) confirms the release of a bearer. 

7.1.2 QS4 

The information flow across this reference point shall communicate QoS policy information relating to the 
establishment of a bearer with specified QoS levels. 

The following primitives are defined: 

QoSPE request (QS4.QoSPEreq) requests authorization for the establishment of a bearer with defined QoS 
characteristics. 

QoSPE confirm (QS4.QoSPEconf) confirms authorization for the establishment of a bearer with defined QoS 
characteristics. 

QoSPE reject (QS4.QoSPErej) rejects authorization for the establishment of a bearer with defined QoS 
characteristics. 

7.1.3 QT2 

The information flow across this reference point shall communicate QoS related transport flow information between a 
Service Domain and an associated Transport Domain. The information on QT2 shall communicate the QoS related 
characteristics required of the transport flows that will carry the media flow, the properties of the media flow, and 
addressing information related to the transport flows. 

The following primitives are defined: 

TRM QoS request (QT2.TRMQreq) requests the establishment of a transport flow with defined QoS characteristics 
across a Transport Domain or the reservation of Transport Domain resource. 

TRM QoS confirm (QT2.TRMQconf) acknowledges the creation of a requested transport flow or the reservation of 
Transport Domain resource. 

TRM QoS reject (QT2.TRMQrej) rejects the creation of a requested transport flow or the reservation of Transport 
Domain resource. 

TRM QoS release request (QT2. TRM QoS relreq) requests the release of a transport flow. 

TRM QoS release confirm (QT2. TRM QoS relconf) confirms the release of a transport flow. 

TRM QoS performance notification (QT2. TRM QoS perfnotif) notifies the Service Domain of the performance of 
the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. 

NOTE: This primitive is a management primitive and its use is for further study. 

7.1.4 QT1 

The information flow across this reference point shall communicate QoS related transport flow information between 
User Equipment QoSM and an associated Transport Domain. The information on QT1 shall communicate the QoS 
related characteristics required of the transport flows that will carry the media flow, the properties of the media flow, 
and addressing information related to the transport flows. 

The following primitives are defined: 

QoS request (QTl.TRMQreq) requests the establishment of a transport flow with defined QoS characteristics across a 
Transport Domain or the reservation of Transport Domain resource. 
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QoS confirm (QTl.TRMQconf) acknowledging the creation of a requested transport flow or the reservation of 
Transport Domain resource. 

QoS reject (QTl.TRMQrej) rejecting the creation of a requested transport flow or the reservation of Transport 
Domain resource. 

QoS release request (QTl.TRMQrelreq) requests the release of a transport flow. 

QoS release confirm (QTl.TRMQrelconf) confirms the release of a transport flow. 

7.1.5 QI1 

The information flow across this reference point shall communicate QoS related transport flow information between a 
User Equipment TRM and a TRM in another Transport Domain. The information on QI1 shall communicate the QoS 
related characteristics required of the transport flows that will carry the media flow, the properties of the media flow, 
and addressing information related to the transport flows. 

The following primitives are defined: 

QoS request (QIl.TRMQreq) requests the establishment of a transport flow with defined QoS characteristics across a 
Transport Domain or the reservation of Transport Domain resource. 

QoS confirm (QIl.TRMQconf) acknowledging the creation of a requested transport flow or the reservation of 
Transport Domain resource. 

QoS reject (QIl.TRMQrej) rejecting the creation of a requested transport flow or the reservation of Transport Domain 
resource. 

QoS release request (QIl.TRMQrelreq) requests the release of a transport flow. 

QoS release confirm (QIl.TRMQrelconf) confirms the release of a transport flow. 

7.1.6 QI2 

The information flow across this reference point shall communicate QoS related transport flow information between 
two associated Transport Domains. The information on QI2 shall communicate the QoS related characteristics required 
of the transport flows that will carry the media flow, the properties of the media flow, and addressing information 
related to the transport flows. 

The following primitives are defined: 

QoS request (QI2.TRMQreq) requests the establishment of a transport flow with defined QoS characteristics across a 
Transport Domain or the reservation of Transport Domain resource. 

QoS confirm (QH.TRMQconf) acknowledges the creation of a requested transport flow or the reservation of 
Transport Domain resource. 

QoS reject (QH.TRMQrej) rejects the creation of a requested transport flow or the reservation of transport domain 
resource. 

QoS release request (QI2.TRMQrelreq) requests the release of a transport flow. 

QoS release confirm (QI2. TRMQrelconf) confirms the release of a transport flow. 
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7.1.7 QI3 



The information flow across this reference point shall communicate QoS related transport flow information between a 
TRM and an ICF within a Transport Domain. The information on QI3 may communicate the QoS related characteristics 
required of the transport flows that will carry the media flow, the properties of the media flow or QoS mechanism 
related information and addressing information related to the transport flows. 

The following primitives are defined: 

QoS request (QB.ICFQreq) requests the establishment of a transport flow with defined QoS characteristics and 
mechanisms into or out of a Transport Domain. 

QoS confirm (QI3.ICFQconf) acknowledging the creation of a requested transport flow. 

QoS reject (QI3.ICFQrej) rejecting the creation of a requested transport flow. 

QoS release request (QD. ICFQ relreq) requests the release of a transport flow. 

QoS release confirm (QI3. ICFQrelconf) confirms the release of a transport flow. 

7.1.8 QI4 

The information flow across this reference point shall contain requests and authorizations for the established of QoS 
controlled transport flows through a Transport Domain and policy related information specific to the QoS mechanisms 
involved. 

NOTE: The information flows on this interface are for further study. 

The following primitives are defined: 

QoS Policy request (QI4.PQreq) requests authorization for the establishment of a transport flow with defined QoS 
characteristics and may request a QoS mechanism and ICF address. 

QoS Policy confirm (QI4.PQconf) provides authorization for the establishment of the transport flow and defines QoS 
mechanism and ICF address. 

QoS Policy reject (QI4.PQrej) rejecting the creation of a requested transport flow. 

7.1.9 QI5 

The information flow across this reference point shall communicate QoS related transport flow information between a 
TRM and Transport Functionality within a Transport Domain. The information on QI5 may communicate the QoS 
related characteristics required of the transport flows and the QoS mechanism related information that will be used to 
achieve this. The information flows on this interface are for further study. 

The following primitives are defined: 

QoS request (QK.TFQreq) requests the establishment of a transport flow with defined QoS characteristics and 
mechanisms within a Transport Domain. 

QoS confirm (QI5.TFQconf) acknowledging the creation of a requested transport flow. 

QoS reject (QI5.TFQrej) rejecting the creation of a requested transport flow. 

QoS release request (QI5.TFQ relreq) requests the release of a transport flow. 

QoS release confirm (QI5.TFQrelconf) confirms the release of a transport flow. 
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7.2 QoS Parameters Groups 
7.2.1 QoS parameter groups 

The QoS primitives defined in clause 8. 1 above shall contain a number of parameters from the following defined 
parameter groups. 



Parameter Group 


Description 


Parameters 


Description 


QoS Service Class 


Describes the 
end-to-end TIPHON 
class of a bearer. 


Best, High, Medium or 
Best Effort. 


Parameters specifying the TIPHON 
QoS Class as defined in 
TS101 329-2 [2]. 


Codec Type and 
Packetization 


Describes the Codec 
type used on a bearer 
and the way the media 
is packetized. 


Codec Type (Optionally a 
list of possible codecs). 


Codec Identifier including any 
relevant codec parameters, e.g. 
version number, sampling rate etc. 


Frames per packet 
(Optionally a list when 
codec lists are specified). 


Number of frames per packet. 


Transport QoS 
Parameters 


Specifies the QoS 
characteristics 
required of the 
transport flow carrying 
the media flow. 


Maximum Delay. 


The maximum delay permitted (ms) 
over either a segment of the 
transport flow or the remaining part 
of the transport flow. 


Maximum Packet Delay 
Variation. 


The maximum packet delay 
variation permitted (ms) over either 
a segment of the transport flow or 
the remaining part of the transport 
flow. 


Maximum Packet Loss. 


The maximum packet loss permitted 
(%) over either a segment of the 
transport flow or the remaining part 
of the transport flow (see note). 


Traffic Descriptor 


Characterizes the 
resource requirements 
of an application data 
flow (excludes 
transport flow resource 
requirements). 


Peak Bit. 


Maximum bit rate (bit/s) of the 
media flow. 


Maximum Packet Size. 


Maximum size of the media packets 


Caller & Callee IDs 


Specifies the identity 
of the calling and 
called parties. As 
defined in 
DTS02003/9. 


Calling ID. 


The identity of the calling party. 


Callee ID. 


The identity of the called party. 


Transport Addresses 


Specifies addressing 
information defining 
the transport flow 
carrying the bearer. 


Originator Transport 
Address. 


The originator transport address 
(typically IP address and port/set of 
ports) within a transport domain. 


Destination Transport 
Address. 


The destination transport address 
(typically IP address and port/set of 
ports) within a transport domain. 


Application Data 
Transport Protocol 


Specifies the 
application data 
transport protocol of 
the bearer. 


Protocol ID. 


Identifier of the application data 
transport protocol used by the 
bearer. Typically RTP. 


Packet Transport 
Protocol 


Specifies the packet 
transport protocol. 


Protocol ID. 


Identifier of the packet transport 
protocol used in the transport flow. 
Typically UDP. 


QoS Policy 


Describes the policy 
determining the users 
entitlement to QoS 
Service Class. 


TBD. 


TBD. 


QoS Mechanism 


Describes the 
mechanism used in 
the Transport Plane. 


Type. 


None, RSVP/INTSERV, DIFFSERV 
or MPLS. 


Mechanism specific 
parameters. 


TBD. 


Authorization Token. 


TBD. 


NOTE: This measure assumes randomly distributed packet loss. 
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7.2.2 QC1 

The following list defines the parameters used in the QC1 primitives. 



Primitive 


Parameter 


Status 


QC1 .QoSMreq 


QoS Service Class 


Mandatory 




Codec Type and Packetization 


Mandatory 




Transport QoS Parameters 






Traffic Descriptor 


Optional 




Transport Addresses 


Optional 




Caller & Called IDs 


Mandatory 




Application Data Transport Protocol 


Mandatory 




Packet Transport Protocol 


Optional [Default RTP] 
Optional [Default UDP] 


QC1 .QoSMconf 


QoS Service Class 


Mandatory 




Codec Type and Packetization 


Mandatory 




Transport QoS Parameters 






Transport Addresses 


Optional 




Application Data Transport Protocol 


Mandatory 




Packet Transport Protocol 


Optional [Default RTP] 




QoS Mechanism 


Optional [Default UDP] 
Optional 


QC1 .QoSMrej 


Reason [TBD] 


Mandatory 



7.2.3 QC2 

The following list defines the parameters used in the QC2 primitives. 



Primitive 


Parameter 


Status 


QC2.QoSMreq 


QoS Service Class 


Optional 




Codec Type and Packetization 


Mandatory 




Transport QoS Parameters 






Traffic Descriptor 


Mandatory 




Transport Addresses 


Optional 




Application Data Transport Protocol 


Mandatory 




Packet Transport Protocol 


Optional [Default RTP] 




QoS Mechanism 


Optional [Default UDP] 
Optional 


QC2.QoSMconf 


QoS Service Class 


Optional 




Codec Type and Packetization 


Mandatory 




Transport QoS Parameters 






Transport Addresses 


Mandatory 




Application Data Transport Protocol 


Mandatory 




Packet Transport Protocol 


Optional [Default RTP] 
Optional [Default UDP] 


QC2.QoSMrej 


Reason [TBD] 


Mandatory 



7.2.4 QS4 

The following list defines the parameters used in the QS4 primitives. 



Primitive 


Parameter 


Status 


QS4.QoSPEreq 


QoS Service Class 
Caller Identity 
Called Identity 


Mandatory 
Mandatory 
Mandatory 


QS4.QoSPEconf 


QoS Service Class 
Caller Identity 
Called Identity 


Mandatory 
Mandatory 
Mandatory 


QS4. QoSPErej 


Reason [TBD] 


Mandatory 



ETSI 



27 



ETSI TS 101 329-3 V1.1.1 (2001-01) 



7.2.5 QT2 

The following list defines the parameters used in the QT2 primitives. 



Primitive 


Parameter 


Status 


QTZTRMQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


Mandatory 
Mandatory 
Mandatory 
Optional [Default UDP] 


QTZTRMQconf 


Transport QoS Parameters 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 


Mandatory 

Mandatory 

Optional [Default UDP] 

Optional 


QTZTRMQrej 


Reason [TBD] 


Mandatory 



7.2.6 QT1 

The following list defines the parameters used in the QT1 primitives. 



Primitive 


Parameter 


Explanation 


QTLTRMQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 


Mandatory 

Optional 

Mandatory 

Optional [Default UDP] 

Optional 


QTLTRMQconf 


Transport QoS Parameters 
Transport Addresses 
Packet Transport Protocol 


Mandatory 
Mandatory 
Optional [Default UDP] 


QTLTRMQrej 


Reason [TBD] 


Mandatory 



7.2.7 



QI1 



The following list defines the parameters used in the QI1 primitives. 



Primitive 


Parameter 


Explanation 


QTLTRMQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 


Mandatory 

Optional 

Mandatory 

Optional [Default UDP] 

Optional 


QTLTRMQconf 


Transport QoS Parameters 
Transport Addresses 
Packet Transport Protocol 


Mandatory 
Mandatory 
Optional [Default UDP] 


QTLTRMQrej 


Reason [TBD] 


Mandatory 



7.2.8 QI2 

The following list defines the parameters used in the QI2 primitives. 



Primitive 


Parameter 


Explanation 


QI2.TRMQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


Mandatory 

Optional 

Mandatory 

Optional [default UDP] 


QI2.TRMQconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


Mandatory 

Optional 

Mandatory 

Optional [default UDP] 


QI2.TRMQrej 


Reason [TBD] 


Mandatory 
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7.2.9 QI3 

The following list defines the parameters used in the QI3 primitives. 



Primitive 


Parameter 


Explanation 


QI3.ICFQreq 


Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 


Optional 

Mandatory 

Optional [default UDP] 

Mandatory 


QI3.ICFQconf 


Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 


Optional 

Optional 

Optional [default UDP] 

Optional 


QI3.ICFQrej 


Reason [TBD] 


Mandatory 



7.2.10 QI4 

The following list defines the parameters used in the QI4 primitives. 



Primitive 


Parameter 


Explanation 


QI4.PQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 


Optional 

Optional 

Mandatory 

Optional [default UDP] 

Optional 


QI4.PQconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
QoS Mechanism 


Optional 
Optional 
Optional 
Optional 


QW.PQrej 


Reason [TBD] 


Mandatory 



7.2.11 QI5 

Details of the parameters and primitives on this reference point are for further study. 
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8 QoS Procedures (Informational) 

The QoS Primitives defined in clause 8 can be used in a number of QoS related procedures. 

8.1 Third Party Establishment of QoS Controlled Bearer 

In this situation a third party, typically a Service Provider, establishes a QoS controlled bearer on behalf of a calling 
party by signalling the required QoS characteristics to the Transport Plane. See clause 5.2.3.1 and figure 3. 

The functional elements involved are shown in the figure 9. The QoSM in the terminal requests service of the QoSM in 
Service Domain 1. This QoSM establishes a QoS controlled bearer by communicating with the TRM in Transport 
Domain 1 and QoSM in Service Domain 2. 





QT2 



ICF1 



QI4 

TRM1 

QI3 1CF2 

Transport Domain 1 




Figure 9: Functional elements involved in Third Party Bearer Establishment 

The information flows are shown in figure 10. 
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UEQoSM 



QoSM QoSPE TRM 
Domain 1 Domain 1 Domain 1 

(1)QC1.QoSMReq 



(2) QS4.QoSPEReq 

(3) QS4.QoSPEConf 



ICF1,2 TPE QoSM 

Domain 1 Domain 2 




(12)QC1.QoSMConf 



(6) QW.PQConf 

(7) QI3.ICFQReq 

(8) QI3.ICFQConf 



(10)QC2.QoSMF!eq 




Figure 10: Information Flows for Third Party QoS Bearer Establishment 



The primitives carry the following parameters. Other optional parameters listed in clause 8 are not required for this 
procedure. 
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Primitive 


Parameter 


QC1 .QoSMreq: 


QoS Service Class 

Codec Type and Packetization 

Application Data Transport protocols 

Packet Transport Protocol 

Caller & Called ID 

Originating Transport Address 


QS4.QoSPEreq 


QoS Service Class 
Caller & Callee IDs 


QS4.QoSPEconf 


QoS Service Class 
Caller& Callee IDs 


QT2.TRMQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QW.PQreq 


Transport QoS parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QW.PQconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 


QI3.ICFQreq 


Traffic Descriptor 

Transport Addresses 

Packet Transport Protocol 

QoS Mechanism (including mechanism parameters) 


QI3.ICFQconf 


Traffic Descriptor 

Transport Addresses 

Packet Transport Protocol 

QoS Mechanism (including mechanism parameters) 


QT2.TRMQconf 


Transport QoS Parameters 
Transport Addresses 
Packet Transport Protocol 


QC2.QoSMreq 


QoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QC2.QoSMconf 


QoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QC1 .QoSMconf 


QoS Service Class 

Codec Type and Packetization 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 
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8.2 First Party Establishment of QoS Controlled Bearer 

In this situation the calling party establishes a QoS controlled bearer directly by signalling the necessary QoS 
characteristics to the Transport Plane. See clause 5.2.3.2 and figure 4. 

The functional elements involved are shown in the figure 1 1 . The QoSM in the initiating terminal first establishes 
compatible codecs via end-to-end Application Plane signalling. At the same time the QoS parameters of the responding 
terminal must be established. QoS transport budgets will then be determined by the QoSM in Service Domain 1 and 
communicated to the QoSM in the initiating terminal. The QoS controlled bearer is then established directly by 
signalling between the initiating terminal and the TRM in Transport Domain 1. This TRM communicates in the usual 
way with the TPE and ICFs in Transport Domain 1 and subsequently with the TRM in Transport Domain 2. 

NOTE: In this scenario the Service Provider cannot only offer guarantees about the quality levels achievable from 
the Transport Plane via fixed parameters in service level agreements with Transport Operators. Other 
factors such as Network Address Translation and Firewalls may also present difficulties. 




Figure 11: Functional elements involved in First Party Bearer Establishment 
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The information flows are shown in figure 12. 



UEQoSM QoSM(1) QoSPE(1) TRM (1) 

(1)QC1.QoSMReq 

(2) QS4.QoSPEReq 

(3) QS4.QoSPEConf 



ICF1,2 TPE(1) QoSM (2) TRM (2) 



(5) QC2.QoSMConf 



(6)QC1.QoSMConf 



(7) QT1 TRMReq 



(8) QW.PQReq 

(9) QW.PQConf 
(10)QI3.ICFQReq 
(11)QI3.ICFQConf 




(4) QC2.GoSMReq 



Figure 12: Information Flows for First Party QoS Bearer Establishment 
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The flows contain the following parameters: 



Primitive 


Parameter 


QC1 .QoSMreq: 


QoS Service Class 

Codec Type and Packetization 

Application Data Transport Protocols 

Packet Transport Protocol 

Caller & Called ID 

Originating Transport Address 


QS4.QoSPEreq 


QoS Service Class 
Caller & Callee IDs 


QS4.QoSPEconf 


QoS Service Class 
Caller& Callee IDs 


QC2.QoSMreq 


QoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QC2.QoSMconf 


QoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QC1 .QoSMconf 


QoS Service Class 

Codec Type and Packetization 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QT1 TRMreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QW.PQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QW.PQconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 


QI3.ICFQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism (see note) 


QI3.ICFQconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QT1 TRMconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


NOTE: Mechanism dependent signalling will take place here. 
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8.3 Hybrid Third Party/First Party Establishment of QoS 
Controlled Bearer via authorization tokens 

In this situation the calling party establishes a QoS controlled bearer directly by signalling the necessary QoS 
characteristics to the Transport Plane but after receiving authorization from a Service Provider. 

This mechanism overcomes some of the difficulties associated with First Party bearer establishment. 

The functional elements involved are shown in the figure 13. The QoSM in the terminal communicated directly with the 
TRM in Transport Domain 1 but also with the QoSM in Service Domain 1 . The TRM in transport Domain 1 
communicates in the usual way with the TPE and ICFs in Transport Domain 1. Remaining legs of the bearer may either 
be established via the Application Plane or by signalling within the Transport Plane between TRMs. 




Figure 13: Functional elements involved 
in Hybrid Third Party/First Party Bearer Establishment 
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The information flows are shown in figure 14: 



UEQoSM QoSM(1) QoSPE(1) TRM (1) 

(1)QC1.QoSMReq 

(2) QS4.QoSPEReq 

(3) QS4.QoSPEConf 



ICF1,2 TPE(1) QoSM (2) TRM (2) 




(6) QW.PQConf 

(7) QI3.ICFQReq 

(8) QI3.ICFQConf 




Figure 14: Information Flows for Hybrid Third Party/First Party Bearer Establishment 
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The flows contain the following parameters: 



Primitive 


Parameter 


QC1 .QoSMreq: 


QoS Service Class 

Codec Type and Packetization 

Application Data Transport Protocols 

Packet Transport Protocol 

Caller & Called ID 

Originating Transport Address 


QS4.QoSPEreq 


QoS Service Class 
Caller & Callee IDs 


QS4.QoSPEconf 


QoS Service Class 
Caller& Callee IDs 


QT2.TRMQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QW.PQreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QW.PQconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
QoS Mechanism 
QoS Token 


QI3.ICFQreq 


Traffic Descriptor 

Transport Addresses 

Packet Transport Protocol 

QoS Mechanism (including mechanism parameters) 

QoS Token 


QI3.ICFQconf 


Traffic Descriptor 

Transport Addresses 

Packet Transport Protocol 

QoS Mechanism (including mechanism parameters) 


QT2.TRMQconf 


Transport QoS Parameters 
Transport Addresses 
Packet Transport Protocol 
QoS Token 


QC2.QoSMreq 


QoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QC2.QoSMconf 


QoS Service Class 

Codec Type and Packetization 

Transport QoS Parameters 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 


QC1 .QoSMconf 


QoS Service Class 

Codec Type and Packetization 

Transport Addresses 

Application Data Transport Protocols 

Packet Transport Protocol 

QoS Token 


QT1 TRMreq 


Transport Addresses 
QoS Token 


QI2.TRMreq 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 


QI2.TRMconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 
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Primitive 


Parameter 


QT1 TRMconf 


Transport QoS Parameters 
Traffic Descriptor 
Transport Addresses 
Packet Transport Protocol 



8.4 Terminal Registration 



For further study. 
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Annex A (Informative): 

Examples of End-to-End QoS Control 

This annex describes a number of different ways in which the general QoS architecture can be used to establish a QoS 
controlled bearer. 



A.1 One service domain/One transport domain 




QoS Signalling 
Call/Bearer Signalling 



■4 ► Transport Signalling 

■4 — ► Media Path 



Figure 15: One Service Domain/One Transport Domain 

In this scenario one service domain and one transport domain are shown. 
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A.2 One service domains/multiple transport domains 
Case I 




< ► QoS Signalling 

"^ ► Call/Bearer Signalling 



A ► Transport Signalling 

A ► Media Path 



Figure 16: One Service Domain/Multiple Transport Domains - Case I 

In this scenario multiple transport domains are under the control of one service domain. 

Each transport domain has a direct relationship with the controlling service domain. The service domain will have to 
arrange the resources and make sure the transport channel is connected end-to-end. 

Such a deployment requires the service domain to be aware of the location of the ICFs of each of the transport domains 
in order to connect them. 
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A. 3 One service domain/multiple transport domains 
Case II 




QoS Signalling 
Call/Bearer Signalling 



Transport Signalling 
Media Path 



Figure 17: One Service Domain/Multiple Transport Domains - Case II 

In this scenario multiple transport domains are shown for one service domain and there is only one interface between 
the application and transport planes. 

The group of transport domains looks to the service domain as one domain. One transport domain may be the master 
contractor communicating with the other TRMs (either in parallel or each TRM communicating with the next) to set up 
the aggregate channel end-to-end. 

The communication between the TRMs will look like the signalling across reference point QT2. 

Such a deployment requires that all the transport domains for each end-to-end bearer must maintain a uniform set of 
policies regarding addressing and QoS mechanisms. Potentially, there will also be issues of security to be addressed in 
passing the QT1 signalling across the boundary of the two transport domains. 
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A. 4 Multiple service domains/multiple transport domains 




< ► QoS Signalling 

•^ ► Call/Bearer Signalling 



-^ ► Transport Signalling 

-^ — ► Media Path 



Figure 18: Multiple Service Domains/Multiple Transport Domains - Case I 

In this scenario the communication between multiple service domains is handled by multiple transport domains. 

The bearer is established by transport Domain 1 as master contract to service Domain 1 so that the subsequent transport 
domains can be considered as extensions of the transport domain belonging to service Domain 1 . 

A.5 Multiple service domains/multiple transport domains 



►^•^^service Domain n Qf+. 



QoSM 




< ► QoS Signalling 

•^ ► Call/Bearer Signalling 



Transport Signalling 
Media Path 



Figure 19: Multiple Service Domains/Multiple Transport Domains - Case II 
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Again in this scenario the communication between multiple service domains is handled by multiple transport domains. 
However several transport domains may be involved in the control of the bearer. 

Each transport domain has a direct relationship with its controlling service domain. The service domain will have to 
arrange the resources and make sure the bearer is connected end-to-end. 

As with Scenario in clause A. 1 . 1 such a deployment requires the service domains to be aware of the location of the ICFs 
of each of the transport domains in order to connect them. 



A. 6 Roaming 




-► Media Path 
-► QoS Signalling 
-► Call Signalling 



TRM 



Transport Resource Manager 



Figure 20: Multiple Service Domains/Multiple Transport Domains - Roaming 

In this scenario a user, registered in Service Domain 0, is visiting Service Domain 1 and sets up a via Service Domain 1. 
The QoSM in Service Domain 1 contacts the QoSPE in Service Domain to ascertain the service profile of the visiting 
user before proceeding to set up the call. 
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A.7 Provisioned VPN 



Service Domain 1 



Service Domain 2 




Media Path 
QoS Signalling 
Call Signalling 



■4 Configuration Instruction 

■4 Configuration Information 



Transport Resource 
Manager 



Figure 21 : Multiple Service Domains/Multiple Transport Domains - Provisioned VPN 
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Annex B (Informative): 

Examples of Mapping of QoS Architecture Functional 

Elements to Physical Elements 

This annex illustrates several different ways in which the Functional elements defined in the present document may be 
incorporated into Network or User equipment. The table lists some of these possibilities. 



Functional Element 


Physical Element 


QoSM 


H.323 Terminal, SIP client, H.323 Gatekeeper, SIP Proxy, 
Softswitch, H.323 Border Element, 3GPP CSCF 


QoSM (BC part) 


Media Gateway Controller, 3GPP MGCF 


QoSM (MC part) 


3GPP MRF, Media Gateway 


QoSPE 


H.323 Gatekeeper, SIP Proxy, SoftSwitch, 3GPP HSS 


TRM 


Router, edge router, Bandwidth Broker 


TRM proxy 


Firewall 


ICF 


Firewall, edge router 


TF 


Router, edge router 


TPE 


Policy Server 



Similarly Reference points will may be associated with physical interfaces on Network or User equipment. Some 
possibilities are listed in the table. 



Physical Element 


Reference Points 


H.323 Terminal 


QC1 , QT1 


SIP client 


QC1 , QT1 


H.323 Gatekeeper 


QC1 , QC2, QT2 


SIP Proxy 


QC1 , QC2, QT2 


SoftSwitch 


QC1 , QC2, QT2 


H.323 Border Element 


QC2, QT2 


Media Gateway Controller 


QC2 


Media Gateway 


QT1, 


Signalling gateway 


QC2 


Router 


QI5, QT1 (e.g. for RSVP),QI4 


Firewall 


QI3, QT1 (e.g. for RSVP) 


edge router 


QI5, QI3, QT1 (e.g. for RSVP),QI4 


Policy server 


QI4 


Bandwidth broker 


QT2, QI1.QI2, QI3, QI4, QI5 


3GPPCSCF 


QC1 , QC2, QT2, 


3GPP HSS 


QS4 


3GPPMGCF 


QC2 


3GPPMRF 


QT1 
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